@julienrf do you understand the versionPolicyCheck failure?

@SethTisue When we bump a dependency of scala-xml, we might, by transitivity, affect downstream users of scala-xml. If we bumped a dependency that is not binary compatible with its previous version, that would introduce a binary incompatibility in scala-xml, by transitivity. Similarly, if we bumped a dependency that is not source compatible with its previous version, that would introduce a source incompatibility in scala-xml, by transitivity. The goal of the task versionPolicyReportDependencyIssues is to detect and report such problems.

The way to deal with these problems is to signal to sbt-version-policy that we intend to break the source compatibility or binary compatibility in scala-xml (by setting versionPolicyIntention accordingly).

Here, our intention is to stay binary and source compatible in scala-xml (as per our versionPolicyIntention), and we want to bump scalajs-library from 1.5.1 to 1.6.0. This artifact does not declare its versioning scheme, so sbt assumes PVP by default (which is probably wrong in the case of scalajs-library, but we need to @sjrd to confirm). Assuming PVP, versions 1.5.1 and 1.6.0 are incompatible (they are even binary incompatible), so it’s not legal to bump this dependency if we intend to keep both binary and source compatibility in scala-xml.

I believe scalajs-library 1.6.0 is actually at least binary compatible with 1.5.1, so its versioning scheme should be semver-spec, not pvp. We can instruct sbt-version-policy as follows:

ThisBuild / versionPolicyDependencySchemes += "org.scala-js" %% "scalajs-library" % "semver-spec"

But still, as long as our intention in scala-xml is to keep source compatibility, this dependency bump is not allowed, we should also relax our intention:

ThisBuild / versionPolicyIntention := Compatibility.BinaryCompatible

That being said, I’ve just checked locally, and found the following bugs in sbt-version-policy:

• versionPolicyReportDependencyIssues only checks for binary incompatibilities, not source incompatibilities (this means that the task will incorrectly succeed in our case even without relaxing our intention to BinaryCompatible)
• Setting versionPolicyDependencySchemes scoped to ThisBuild does not work, we have to scope it to the project xmlJS.

scalajs-library uses "early-semver" (which is equivalent to "semver-spec" when >= 1.0.0) of course. (I mean, I've been the strongest advocate of that versioning scheme.) So 1.6.0 is backward binary compatible but not source compatible. This is also stated in https://www.scala-js.org/news/2021/06/09/announcing-scalajs-1.6.0/

thanks for clarifying. I've made the suggested changes

You’re welcome. Remember to reset versionPolicyIntention to BinaryAndSourceCompatible after the next release of scala-xml.